Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement Query pipeline for InMemory provider #17589

Merged
merged 21 commits into from
Sep 3, 2019
Merged

Conversation

smitpatel
Copy link
Contributor

@smitpatel smitpatel commented Sep 3, 2019

Close #16963

Description

As previously discussed with Tactics, this PR includes an updated in-memory database provider such that it works with the 3.0 query pipeline.

Customer Impact

Customers currently cannot use the in-memory provider for many non-trivial queries. This change brings back this functionality.

How found

Planned.

Test coverage

We have re-enabled thousands of tests using the in-memory provider that were previously only running for the relational providers.

Regression?

Yes, from 2.2.

Risk

There is very little risk of breaking anything outside of the in-memory provider, and the in-memory provider is primarily used by customers for testing.

ajcvickers and others added 21 commits September 3, 2019 09:26
Bug blocking those tests has been fixed in previous checkin (support for OfType and Is for InMemory)
Don't send shapers to ServerQueryExpression
Laying ground work for collection projection

Part of #16963
Allow ExpressionTranslator to return null
Fix bug in OfType
Return null for unmapped property to fail gracefully

Part of #16963
When we bind to a non-nullable property on entity that can be nullable (e.g. due to left join) we modify the result to be nullable, to avoid "nullable object must have a value" errors. This nullability is then propagated further. We have few blockers:
- predicates (Where, Any, First, Count, etc): always need to be of type bool. When necessary we add "== true".
- conditional expression Test: needs to be bool, same as above
- method call arguments: we can't reliably rewrite methodcall when the arguments types change (generic methods specifically), we convert arguments back to their original types if they were changed to nullable versions.
- method call caller: if the caller was changed from non-nullable to nullable we still need to call the method with the original type, but we add null check before - caller.Method(args) -> nullable_caller == null ? null : (resultType?)caller.Method(args)
- selectors (Select, Max etc): we need to preserve the original result type, we use convert
- anonymous type, array init: we need to preserve the original type, we use convert

Also enable GearsOfWar and ComplexNavigation tests for in memory.
Filed #17498 to add logging
Resolves #17245
Update issues references and add area for #16963
Enable tests which are already working
Fixed cases involving member pushdown. We now remove all converts from nullable to non-nullable (even ones explicitly added by users) so that nullability can propagate to the very top.
@smitpatel smitpatel requested a review from a team as a code owner September 3, 2019 16:41
@JunTaoLuo
Copy link
Contributor

Is this an Ask Mode change?

@smitpatel
Copy link
Contributor Author

Yes.

@ajcvickers ajcvickers added this to the 3.0.0 milestone Sep 3, 2019
@smitpatel smitpatel merged commit b9f518e into release/3.0 Sep 3, 2019
@ghost ghost deleted the feature/in-memory branch September 3, 2019 23:28
@ajcvickers ajcvickers removed this from the 3.0.0 milestone Sep 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants